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Logical-Interface Support for IP Hosts with Multi-Access Support 
Abstract 


A logical interface is a software semantic internal to the host 
operating system. This semantic is available in all popular 
operating systems and is used in various protocol implementations. 
Logical-interface support is required on the mobile node attached to 
a Proxy Mobile IPv6é domain for leveraging various network-based 
mobility management features such as inter-technology handoffs, 
multihoming, and flow mobility support. This document explains the 
operational details of the logical-interface construct and the 
specifics on how link-layer implementations hide the physical 
interfaces from the IP stack and from the network nodes on the 
attached access networks. Furthermore, this document identifies the 
applicability of this approach to various link-layer technologies and 
analyzes the issues around it when used in conjunction with various 
mobility management features. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7847. 
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1. Introduction 


Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility 
management protocol standardized by IETF. One of the key goals of 
the PMIPv6 protocol is to enable a mobile node to perform handovers 
across access networks based on different access technologies. The 
protocol was also designed with the goal to allow a mobile node to 
simultaneously attach to different access networks and perform flow- 
based access selection [RFC7864]. The base protocol features 
specified in [RFC5213] and [RFC5844] have support for these 
capabilities. However, to support these features, the mobile node is 
required to be enabled with a specific software configuration known 
as logical-interface support. The logical-interface configuration is 
essential for a mobile node to perform inter-access handovers without 
impacting the IP sessions on the host. 


A logical-interface construct is internal to the operating system. 

It is an approach of interface abstraction, where a logical link- 
layer implementation hides a variety of physical interfaces from the 
IP stack. This semantic was used on a variety of operating systems 
to implement applications such as Mobile IP client [RFC6275] and 
IPsec VPN client [RFC4301]. Many host operating systems have support 
for some form of such logical-interface construct. But, there is no 
specification that documents the behavior of these logical interfaces 
or the requirements of a logical interface for supporting the above- 
mentioned mobility management features. This specification attempts 
to document these aspects. 


The rest of the document provides a functional description of a 
logical interface on the mobile node and the interworking between a 
mobile node using a logical interface and the network elements in the 
Proxy Mobile IPv6 domain. It also analyzes the issues involved with 
the use of a logical interface and characterizes the contexts in 
which such usage is appropriate. 


2. Terminology 


All the mobility-related terms used in this document are to be 
interpreted as defined in the Proxy Mobile IPv6 specifications 
[RFC5213] and [RFC5844]. In addition, this document uses the 
following terms: 


PIF (Physical Interface): A network interface module on the host 
that is used for connecting to an access network. A host 
typically has a number of network interface modules, such as 
Ethernet, Wireless LAN, LTE, etc. Each of these network 
interfaces can support specific link technology. 
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LIF (Logical Interface): A virtual interface in the IP stack. A 
logical interface appears to the IP stack just as any other 
physical interface and provides similar semantics with respect to 
packet transmit and receive functions to the upper layers of the 
IP stack. However, it is only a logical construct and is not a 
representation of an instance of any physical hardware. 


SIF (Sub-Interface): A physical or logical interface that is part of 
a logical-interface construct. For example, a logical interface 
may have been created by abstracting two physical interfaces, LTE 
and WLAN. These physical interfaces, LTE and WLAN, are referred 
to as sub-interfaces of that logical interface. In some cases, a 
sub-interface can also be another logical interface, such as an 
IPsec tunnel interface. 


3. Hiding Link-Layer Technologies -- Approaches and Applicability 


There are several techniques that allow hiding changes in access 
technology changes from the host layer. These changes in access 
technology are primarily due to the host’s movement between access 
networks. This section classifies these existing techniques into a 
set of generic approaches, according to their most representative 
characteristics. Later sections of this document analyze the 
applicability of these solution approaches for supporting features, 
such as inter-technology handovers and IP flow mobility support for a 
mobile node. 


3.1. Link-Layer Abstraction -- Approaches 


The following generic mechanisms can hide access technology changes 
from the host IP layer: 


o Link-Layer Support -- Certain link-layer technologies are able to 
hide physical media changes from the upper layers. For example, 
IEEE 802.11 is able to seamlessly change between IEEE 802.11la/b/g 
physical layers. Also, an 802.11 Station (STA) can move between 
different access points within the same domain without the IP 
stack being aware of the movement. In this case, the IEEE 802.11 
Media Access Control (MAC) layer takes care of the mobility, 
making the media change invisible to the upper layers. Another 
example is IEEE 802.3, which supports changing the rate from 10 
Mbps to 100 Mbps and to 1000 Mbps. Another example is the 
situation in the 3GPP Evolved Packet System [TS23401] where the 
User Equipment (UE) can perform inter-access handovers between 
three different access technologies (2G GSM/EDGE Radio Access 
Network (GERAN), 3G Universal Terrestrial Radio Access Network 
(UTRAN), and 4G Evolved UTRAN (E-UTRAN)) that are invisible to the 
IP layer at the UE. 
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o A logical interface denotes a mechanism that logically groups 
several physical interfaces so they appear to the IP layer as a 
single interface (see Figure 1). Depending on the type of access 
technologies, it might be possible to use more than one physical 
interface at a time -- such that the node is simultaneously 
attached via different access technologies -- or just perform 
handovers across a variety of physical interfaces. Controlling 
the way the different access technologies are used (simultaneous, 
sequential attachment, etc.) is not trivial and requires 
additional intelligence and/or configuration within the logical- 
interface implementation. The configuration is typically handled 
via a connection manager, and it is based on a combination of user 
preferences on one hand and operator preferences such as those 
provisioned by the Access Network Discovery and Selection Function 
(ANDSF) [TS23402] on the other hand. The IETF Interfaces MIB 
specified in [RFC2863] and the YANG data model for interface 
management specified in [RFC7223] treat a logical interface just 
like any other type of network interface on the host. This 
essentially makes the logical interface a natural operating system 
construct. 


3.2. Link-Layer Support 


Link-layer mobility support applies to cases in which the same link- 
layer technology is used and mobility can be fully handled at that 
layer. One example is the case where several 802.11 access points 
are deployed in the same subnet with a common IP-layer configuration 
(DHCP server, default router, etc.). In this case, the handover 
across access points need not be hidden to the IP layer since the IP- 
layer configuration remains the same after a handover. This type of 
scenario is applicable to cases when the different points of 
attachment (i.e., access points) belong to the same network domain, 
e.g., enterprise, hotspots from same operator, etc. 


Since this type of link-layer technology does not typically allow for 
simultaneous attachment to different access networks of the same 
technology, the logical interface would not be used to provide 
simultaneous access for purposes of multihoming or flow mobility. 
Instead, the logical interface can be used to provide inter-access 
technology handover between this type of link-layer technology and 
another link-layer technology, e.g., between IEEE 802.11 and IEEE 
802.16. 
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3.3. Logical Interface 


The use of a logical interface allows the mobile node to provide a 
single-interface perspective to the IP layer and its upper layers 
(transport and application). Doing so allows inter-access technology 
handovers or application flow handovers to be hidden across different 
physical interfaces. 


The logical interface may support simultaneous attachment in addition 
to sequential attachment. It requires additional support at the node 
and the network in order to benefit from simultaneous attachment. 

For example, special mechanisms are required to enable addressing a 
particular interface from the network (e.g., for flow mobility). In 
particular, extensions to PMIPv6 are required in order to enable the 
network (i.e., the mobile access gateway (MAG) and local mobility 
anchor (LMA)) to deal with the logical interface, instead of using 
extensions to IP interfaces as currently specified in RFC 5213. RFC 
5213 assumes that each physical interface capable of attaching to a 
MAG is an IP interface, while the logical-interface solution groups 
several physical interfaces under the same IP logical interface. 


It is therefore clear that the logical-interface approach satisfies 
the requirement of multi-access technology and supports both 
sequential and simultaneous access. 


4. Technology Use Cases 


3GPP has defined the Evolved Packet System (EPS) for heterogeneous 
wireless access. A mobile device equipped with 3GPP and non-3GPP 
wireless technologies can simultaneously or sequentially connect to 
any of the available access networks and receive IP services through 
any of them. This document focuses on employing a logical interface 
for simultaneous and sequential use of a variety of access 
technologies. 


As mentioned in the previous sections, the logical-interface 
construct is able to hide from the IP layer the specifics of each 
technology in the context of network-based mobility (e.g., in multi- 
access technology networks based on PMIPv6). The LIF concept can be 
used with at least the following technologies: 3GPP access 
technologies (3G and LTE), IEEE 802.16 access technology, and IEEE 
802.11 access technology. 


In some UE implementations, the wireless connection setup is based on 
creation of a PPP interface between the IP layer and the wireless 
modem that is configured with the IP Control Protocol (IPCP) and IPv6 
Control Protocol (IPv6CP) [RFC5072]. In this case, the PPP interface 
does not have any layer 2 (L2) addresses assigned. In some other 
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implementations, the wireless modem is presented to the IP layer as a 
virtual Ethernet interface. 


5. Logical-Interface Functional Details 


This section identifies the functional details of a logical interface 
and provides some implementation considerations. 


On most operating systems, a network interface is associated with a 
physical device that offers the services for transmitting and 
receiving IP packets from the network. In some configurations, a 
network interface can also be implemented as a logical interface, 
which does not have the inherent capability to transmit or receive 
packets on a physical medium, but relies on other physical interfaces 
for such services. An example of such configuration is an IP tunnel 
interface. 


An overview of a logical interface is shown in Figure 1. The logical 
interface allows heterogeneous attachment while making changes in the 
underlying media transparent to the IP stack. Simultaneous and 
sequential network attachment procedures are therefore possible, 
enabling inter-technology and flow mobility scenarios. 


+---------------------------- + 
| TCP/UDP | 
Session-to-IP +---->| | 
Address Binding | A eis SaaS ees Saas + 
+----> IP 
IP Address +----> 
Binding | tans ose eo Ss eS + 
+----> | Logical Interface | 
Logical-to- +----> | IPv4/IPv6 Address | 
Physical | a N EE E E + 
Interface +----> L2 L2 L2 
Binding (IF#1) | (IF#2)| ..... (IF#n) 
+------ +------ + +------ + 
l EE- ER, ol lif 7a S 
| | | | | 
+------ +------ + +------ + 


Figure 1: General Overview of Logical Interface 


From the perspective of the IP stack and the applications, a logical 
interface is just another interface. In fact, the logical interface 
is only visible to the IP and upper layers when enabled. A host does 
not see any operational difference between a logical and a physical 
interface. As with physical interfaces, a logical interface is 
represented as a software object to which IP address configuration is 
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bound. However, the logical interface has some special properties 
that are essential for enabling inter-technology handover and flow- 
mobility features. Following are those properties: 


1. The logical interface has a relation to a set of physical 
interfaces (sub-interfaces) on the host that it is abstracting. 
These sub-interfaces can be attached or detached from the logical 
interface at any time. The sub-interfaces attached to a logical 
interface are not visible to the IP and upper layers. 


2. The logical interface may be attached to multiple access 
technologies. 

3. The Transmit/Receive functions of the logical interface are 
mapped to the Transmit/Receive services exposed by the sub- 
interfaces. This mapping is dynamic, and any change is not 


visible to the upper layers of the IP stack. 


4. The logical interface maintains IP flow information for each of 
its sub-interfaces. A conceptual data structure is maintained 
for this purpose. The host may populate this information based 
on tracking each of the sub-interfaces for the active flows. 


5.1. Configuration of a Logical Interface 


A host may be statically configured with the logical-interface 
configuration, or an application such as a connection manager on the 
host may dynamically create it. Furthermore, the set of sub- 
interfaces that are part of a logical-interface construct may be a 
fixed set or may be kept dynamic, with the sub-interfaces getting 
added or deleted as needed. The specific details related to these 
configuration aspects are implementation specific and are outside the 
scope of this document. 


The IP layer should be configured with a default router reachable via 
the logical interface. The default router can be internal to the 
logical interface, i.e., it is a logical router that in turn decides 
which physical interface is to be used to transmit packets. 
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5.2. Logical-Interface Conceptual Data Structures 


Every logical interface maintains a list of sub-interfaces that are 
part of that logical-interface construct. This is a conceptual data 
structure, called the LIF table. Figure 2 shows an example LIF table 
where logical interface LIF-1 has three sub-interfaces, ETH-O, 
WLAN-0, and LTE-O, and logical interface LIF-2 has two sub- 
interfaces, ETH-1 and WLAN-1. For each LIF entry, the table should 
store the associated link status and policy associated with that sub- 


interface (e.g., active or not active). The method by which the 
routing policies are configured on the host is out of scope for this 
document. 

+ + + + 
| Logical_Interface | Sub_Interface | Status/Policy 

+ + + + 
| LIF-1 | ETH-0 | UP | 
+ + + + 
| LIF-1 | WLAN-0 | DOWN | 
+ + + + 
| LIF-1 | LTE-0 | UP | 
+ + + + 
| LIF-2 | ETH-1 | UP | 
+ + + + 
| LIF-2 | WLAN-1 | UP | 
+ + + + 


Figure 2: Logical-Interface Table 


The logical interface also maintains the list of flows associated 
with a given sub-interface, and this conceptual data structure is 
called the Flow table. Figure 3 shows an example Flow table, where 
flows FID-1, FID-2, FID-3, FID-4, and FID-5 are associated with sub- 
interfaces ETH-0, WLAN-0, LTE-0, ETH-1, and WLAN-1, respectively. 
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+ 

Flow | Sub_Interface 
+ 

FID-1 | ETH-0 
+ 

FID-2 | WLAN-0 
+ 

FID-3 | LTE-0 
+ 

FID-4 | ETH-1 
+ 

FID-5 | WLAN-1 
+ 


Figure 3: Flow Table 


+— + — + — + — + — ++ 
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The Flow table allows the logical interface to properly route each IP 


flow over a specific sub-interface. 


The logical interface can 


identify the flows arriving on its sub-interfaces and associate them 
This approach is similar to reflective QoS 


to those sub-interfaces. 
performed by the IP routers. 


unicast flows), 


selection based on the Flow Routing Policies. 


For locally generated traffic 


(e.g., 


the logical interface should perform interface 


In case traffic of an 


existing flow is suddenly received from the network on a different 
sub-interface from the one locally stored, the logical interface 
should interpret the event as an explicit flow mobility trigger from 
the network, and it should update the corresponding entry in the Flow 


table. Similarly, 


locally generated events from the sub-interfaces 


or configuration updates to the local policy rules can cause updates 
to the table and hence trigger flow mobility. 
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6. Logical-Interface Use Cases in Proxy Mobile IPv6 


This section explains how the logical-interface support on the mobile 
node can be used for enabling some of the Proxy Mobile IPv6 protocol 
features. 


6.1. Multihoming Support 
Figure 4 shows a mobile node with multiple interfaces attached to a 
Proxy Mobile IPv6 domain. In this scenario, the mobile node is 
configured to use a logical interface over the physical interfaces 


through which it is attached. 


LMA Binding Table 


+ + 
+----+ | HNP MN-ID CoA ATT | 
|LMA | + + 
+----+ | HNP-1 MN-1 PCoA-1 5 | 
FENN | HNP-1 MN-1 PCoA-2 4 | 
te SSS MIRSANANA StS aS Sse + 
( // \\ ) 
( // \\ ) 
Poest [=R \ Nare + 
// \\ 
PCoA-1 // \\ PCoA-2 
+----+ +----+ 
(WLAN) |MAG1 | |MAG2| (3GPP) 
+----+ +----+ 
\ / 
X / 
\ / 
\ / 
\ / 
4+------- + 4+------- + 
paet [| eee || 
| (WLAN) | |(3GPP) | 
4+------- +-+------- + 
| Logical | 
| Interface | 
| (HNP-1) 
+ [oa a ey Say ee eee ee aa ae a Py 
| MN | 
4+----------------- + 


Figure 4: Multihoming Support 
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Inter-technology Handoff Support 


The Proxy Mobile IPv6 protocol enables a mobile node with multiple 
network interfaces to move between access technologies but still 


retain the same address 
Figure 5 shows a mobile 
between access networks 


achieve address continuity during handoffs. 


configuration on its attached interface. 
node performing an inter-technology handoff 
. The protocol enables a mobile node to 

If the host is 


configured to use a logical interface over the physical interface 


through which it is attached, 


following are the related 


considerations. 
LMA’s Binding Table 
+ + 
+----+ | HNP MN-ID CoA ATT | 
|LMA | + + 
+----+ | HNP-1 MN-1 PCoA-1 5 | 
//\\ (pCoA-2) (4) <--change 
tas SAHARA PI ANNTA SAEs + 
( // \\ ) 
( // \\ ) 
FESSes= II a a \N\HSS=s35= + 
el \\ 
PCoA-1 // \\ PCoA-2 
+----+ +----+ 
(WLAN) |MAG1 | |MAG2| (3GPP) 
+----+ +----+ 
\ / 
\ Handoff / 
\ / 
\ / 
+------- + 4+------- + 
patai oil} ji meee. "| 
| (WLAN) | |(3GPP) | 
+------- +-+4+------- + 
| Logical | 
| Interface | 
| (HNP-1) | 
+----------------- | 
| MN | 
+----------------- + 
Figure 5: Inter-technology Handoff Support 
o When the mobile node performs a handoff between if_1 and if_2, the 


change will not be visible to the applications of the mobile node. 


Melia & Gundavelli 


Informational [Page 12] 


RFC 7847 Logical-Interface Support May 2016 


O The protocol signaling between the network elements will ensure 
the local mobility anchor will switch the forwarding for the 
advertised prefix set from MAG1 to MAG2. 


6.3. Flow Mobility Support 


To support IP flow mobility, there is a need to support vertical 
handoff scenarios such as transferring a subset of a prefix(es) 
(hence the flows associated to it/them) from one interface to 
another. The mobile node can support this scenario by using the 
logical-interface support. This scenario is similar to the inter- 
technology handoff scenario defined in Section 6.2; only a subset of 
the prefixes are moved between interfaces. 


Additionally, IP flow mobility in general initiates when the LMA 
decides to move a particular flow from its default path to a 
different one. The LMA can decide the best MAG to be used to forward 
a particular flow when the flow is initiated (e.g., based on 
application policy profiles) and/or during the lifetime of the flow 
upon receiving a network-based or a mobile-based trigger. However, 
the specific details on how the LMA can formulate such flow policy is 
outside the scope of this document. 


7. Security Considerations 


This specification explains the operational details of a logical 
interface on an IP host. The logical-interface implementation on the 
host is not visible to the network and does not require any special 
security considerations. 


Different layer 2 interfaces and the access networks to which they 
are connected have different security properties. For example, the 
layer 2 network security of a Wireless LAN network operated by an end 
user is in the control of the home user whereas an LTE operator has 
control of the layer 2 security of the LTE access network. An 
external entity using lawful means, or through other means, obtains 
the security keys from the LTE operator, but the same may not be 
possible in the case of a Wireless LAN network operated by a home 
user. Therefore, grouping interfaces with such varying security 
properties into one logical interface could have negative 
consequences in some cases. Such differences, though subtle, are 
entirely hidden by logical interfaces and are unknown to the upper 
layers. 
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